The present invention is related to communications networks and, in particular, to a system for processing a record of events recorded during use of the communications networks.
In a traditional revenue-bearing communications network, such as the public switched telephone network (PSTN), a network owner or xe2x80x9cservice providerxe2x80x9d assesses charges to each user or xe2x80x9cservice subscriber.xe2x80x9d Subscribers pay for accessing and using the network and the charges assessed may be based upon a fixed fee, distance and duration of a connection, amount of data transferred, use of special services, etc.
To measure usage by each subscriber, various points in the network may keep a record of connections or data flow through the network on behalf of each subscriber. For example, in a telephone network, the switches that route calls keep a record of each call handled. For practical reasons, these records have traditionally been stored locally at each switch and periodically collected to do billing processing. The records are also used for deriving traffic statistics and for detecting patterns of fraudulent use.
Because a given connection, such as a long-distance telephone call, may involve several switches, several separate call records will be generated in the course of handling the call. During billing processing, these records must be sorted out from the millions of other records collected from all the switches in the network. The correlated records are then assembled to give a composite description of what network resources were used during the particular call and accordingly what charges are to be billed to the appropriate subscribers.
The software that controls each switch is designed to record selected events that occur during call processing and to encode these events into a very specific format. The traditional method of encoding events is known as Automatic Message Accounting (AMA) and is described in an industry standards document designated GR-1100-CORE which may be obtained from Telcordia Technologies. In summary, the encoding format is a well-defined static data structure, also referred to in the industry as a Call Detail Record (CDR). Individual call records are bundled into blocks, which the switch writes to magnetic tapes or other forms of persistent storage.
After collecting the call records from a network that have accumulated over a period of time, a billing processing system must decode and interpret the significance of the content of billing records as encoded by the switches and other network elements. To assure accurate billing processing, the syntax and semantics of the CDR must be commonly understood by both the network elements that generate records and the processing systems that interpret the records.
Software in the billing processor is designed to parse and process call records assuming a particular structure and content. Any change to the CDR semantics or syntax requires a change in the billing code. This change may be necessitated by introduction of a new billable service or feature. For example, the introduction of new service that allows billing a toll telephone call to a debit card or to a third party requires new information be encoded in the CDR.
In the telephone network of the past, new services were introduced relatively infrequently. Reducing time-to-market was not a high priority for service providers. More recently, however, competition among service providers and availability of new capabilities, driven by subscriber demand, have accelerated the introduction of new features.
The burden of changing billing systems code hinders the introduction of new features in a communications network. The traditional fixed-length CDR is relatively inflexible and unnecessarily confining. Since the time that the CDR was first introduced, communications bandwidths and processing speeds have improved many-fold, obviating the need to keep the CDR compact. Many advantages can now be realized in departing from the traditional CDR format.
Accordingly, what is required is an improved method for collecting, conveying and processing recorded event information in a communications network that does not require extensive rewriting and testing of billing systems software whenever a new billable feature is added to the network. This requirement is generally applicable to any records resulting from providing communications service that need to be processed for whatever reason, whether it be billing, fraud detection, traffic analysis, etc.
Technologies are currently being implemented whereby a single communications network may offer users a variety of traffic types, bandwidths, transport technologies and special services. Accordingly, there is a need for generic and readily extensible post-processing systems to cooperatively function with communications systems.
There is also incidentally a need for more general terminology to characterize such communications and post-processing systems. Though the concepts and terminology of a xe2x80x9ccallxe2x80x9d and of xe2x80x9ccall processingxe2x80x9d have long been applied in the context of a traditional telephone network, the broader terms of a xe2x80x9csessionxe2x80x9d and of xe2x80x9cservice processingxe2x80x9d are more appropriate to encompass all uses of a more modern network. A xe2x80x9csessionxe2x80x9d as used herein refers to an instance of use of the network and may comprise the delivery of a single data packet, the establishment of a temporary two-way voice channel, or the transport of a large multimedia file, to name a few examples. The term xe2x80x9cservice processingxe2x80x9d generally refers to the decisions made and actions performed by the network to fulfill the needs of network users.
Referring to FIG. 1 of the drawings, a communications network 100 is shown to comprise switches 112, 114 and 116 interconnected by groups of communications links 120 and 122, sometimes referred to as xe2x80x9ctrunks.xe2x80x9d This collection of switches and links is said to constitute a traffic-bearing network 110. In the example of FIG. 1, traffic-bearing network 110 serves to transport information among various subscriber locations 102a-102i. 
The actions of switches 112, 114 and 116 in network 110 need to be coordinated to route data or otherwise connect subscribers. Accordingly, a switch controller/call processor 132 is coupled so as to control switch 112. Whereas switch 112 directly handles subscriber traffic, switch controller/call processor 132 directs switch 112 to make connections among specific ports. In some practical implementations, some or all of the functional pieces of switch controller/call processor 132 are integrated or collocated with switch 112.
Likewise, switches 114 and 116 in FIG. 1 are controlled by switch controller/call processors 134 and 136, respectively.
Each of the switch controller/call processors in FIG. 1 are connected to a packet-switched signaling network 150 which is, in turn, coupled to at least one service control point 160.
Through signaling network 150, switch controllers 132, 134, and 136 may communicate among one another using, for example, Common Channel Signaling System #7 (SS7). Moreover, switch controllers 132, 134, and 136 may access service control point 160 to determine how to route a given traffic demand. In a typical telephone network, SCP 160 commonly includes a database for performing number translations, such as mapping of 1-800 number telephone calls to actual destination numbers. Service control point 160 maintains data that affects how traffic-bearing network 10 fulfills subscriber requests.
As shown in FIG. 1, a service management system (SMS) 170 is coupled for downloading service-controlling data into SCP 160. In a typical intelligent network as shown in FIG. 1, the software instructions that determine the behavior of the switches and call processors are xe2x80x9cbuilt-inxe2x80x9d or manually loaded into the equipment. There is no mechanism for distributing actual operating software to these elements via SMS 170 or SCP 160. Instead, limited control of the operation of network 100 is exercised by changing the content of data tables at SCP 160. One aspect of the software that controls switch controller/call processor 132 creates records incidental to call processing. These records contain information about instances of usage by subscribers and are commonly used to calculate the amount that each subscriber must pay for their usage of the network, usually over a given period of time. These records are accumulated into a call detail record file 142.
Likewise, switch controller/call processors 134 and 136 accumulate call detail record files 144 and 146, respectively.
Because the elements that generate call detail records are usually located a considerable distance apart, separate call detail record files are accumulated at each site and then periodically collected to be processed.
FIG. 2 depicts the prior art approach to collecting and processing CDR files. In FIG. 2, CDR files 142,144, and 146 that have been accumulated during call processing within network 100 are combined and submitted to various processing functions. A billing processing function 210 processes CDR files to derive billing for each subscriber who uses the network. The aggregated CDR files are first parsed by a file parsing stage 212 that yields separate billing records 213. Resulting parsed billing records are input to a record correlating/parsing function 214, that correlates CDR""s and composes a description of each call handled by the network. This function is particularly important for matching up CDR""s from multiple locations related to a given call. Record correlating/parsing function 214 may also screen for discrepancies among the CDR""s. As a consistent description of each call assembled from the CDR""s, a record data instance 215 is output to a bill analysis function 216. Bill analysis function 216 reviews the billable aspects of each call, applies the appropriate billing rates to the recorded usage, and adds the charges to each subscriber""s bill. The output of a bill analysis function 216 is a bill 218 for each subscriber.
A fraud analysis function 220 may similarly process the CDR files for the purpose of detecting fraud patterns, rather than calculating billing. The stages of file parsing 222 to yield billing records 223 and record correlating/parsing 224 to yield record data instance 225 are comparable to the functions within the billing processor function 210. The fraud analysis stage 226 reviews the progress of individual calls, as well as similarities among multiple calls that may indicate unusual activity. A report of fraud results 228 is generated to highlight any significant fraud-related findings from the processing of fraud analysis 226.
A traffic analysis function 230 may similarly process the CDR files for the purpose of optimizing the operation or design of the network. The stages of file parsing 232 to yield billing records 233 and record correlating/parsing 234 to yield record data instance 235 are comparable to the functions within the billing processor function 210. The traffic analysis stage 236 reviews usage patterns, such as the quantity and duration of calls in a given portion of the network, that may be useful for directing resource utilization within the network or for planning growth of the network. A report of traffic analysis results 238 is generated to summarize the findings of traffic analysis 236.
Billing processor 210, fraud analysis processor 220, and traffic analysis processor 230 are typically implemented in software to run upon a computer and are typically maintained separately from one another, perhaps even in different programming languages or upon different computing platforms. Any change in the syntax or semantics in the CDR""s that are processed may necessitate changes and re-testing of all three of these software implementations. FIG. 3 shows the structure of a typical call detail record file 300 according to the prior art, comparable to CDR files 142, 144, and 146 mentioned above. CDR file 300 is essentially a concatenation of numerous fixed-length CDR""s, depicted in FIG. 3 by records 304a . . . 304n. CDR file 300 also includes a header 302 to provide general information about the file, such as the number of records in the file or the identity of the network element that generated the records. A trailer 306 may also be included to facilitate certain types of data processing or storage. Trailer 306 may, for example, contain a checksum derived from the CDR records that may be useful for checking the integrity of the data file. Records 304a . . . 304n in call detail record file 300 merely contain data representing values such as phone numbers and feature groups. Call detail record file 300 contains no expression of processing logic or instructions.
The present invention is directed to creating and manipulating service processing records in a communications network wherein a service processing record comprises instructions for interpreting the recorded data described in the record. As used herein, the term xe2x80x9cinstructionsxe2x80x9d refers generally to a codification of how something is to be handled. Instructions may take the form of, for example, executable code, pseudo-code, source code, scripting or mark-up language, a simple data structure, or a mixture thereof. Where the term xe2x80x9cmethodsxe2x80x9d is used below for clarity to describe processing instructions that are conveyed within a service processing record, it should be understood that the more general concept of xe2x80x9cinstructionsxe2x80x9d that affect record processing is equally applicable in each instance.
In accordance with a preferred embodiment of the present invention, a processing record comprises instructions in the form of executable code for interpreting the recorded data described in the record.
In accordance with another aspect, the present invention is directed to service processing records that are created, accumulated, and packaged with appropriate functionality, then forwarded to a billing processing system based upon an arbitrary bundling and dispatching policy.
In accordance with a preferred embodiment of the present invention, service processing records conform to a prescribed executable format, such as a JAVA executable. (JAVA is a registered trademark of Sun Microsystems.)
Service processing records may be originated by any network element or service processing function in a communications network. Service processing records may be associated with connections, sessions, or other transactions involving the network. Aside from assessing charges to be billed to subscribers, service processing records may also be processed to identify fraud patterns, analyze consumer trends, and facilitate network capacity engineering. Each service processing record comprises service processing event data and, according to the present invention, may further comprise instructions, such as methods or callable functions, for interpreting and processing the service processing event data.
Service processing records in accordance with the present invention are packaged as executable code, wherein methods are encoded as callable functions and events are encoded as calls to those functions using parameters relevant to the specific instances of the events.
A service processing record of this type may be processed by a general-purpose processing system that extracts the functional content from the record and then uses the methods to interpret and process the data in the record. Whenever a new service or billable feature is added to a network, new or modified service processing functions are deployed to network elements, such as switches and routers, throughout the network. When service processing functions are upgraded with new capabilities, certain portions of the service processing functions that generate service processing records can be designed to include billing and other post-processing methods into the service processing records that are subsequently generated and dispatched. Thus, billing functionality is produced and distributed along with the service processing functionality. In other words, this approach allows the creation and deployment of billing function to be integral with that of service processing functions.
In contrast to prior art record processing systems that use dedicated-purpose hardware and software, event records generated in accordance with the present invention may be handled by a general-purpose post-processing system that extracts the instructions from the service processing event records and then uses the instructions for processing the recorded events. Changes to billing function are created and distributed at the same time as service function. Therefore, billing function need not be maintained and tested separately from service functions. This results in faster implementation of new services in a communications network.
As described earlier, a service processing record as conveyed to a record processor comprises instructions that affect how event data is interpreted and processed in the record processor. Although the prior art call detail records included multiple data fields that were interpreted in context of one another, the methods by which the multiple data fields were processed in context with one another were entirely fixed within the software and hardware of the record processor. Consequently, the semantics of the data fields in the prior art CDR were established by convention. In contrast, the present invention permits data fields to be dynamically re-purposed based on other content in the record and as decided by logic operating outside of the record processor. In fact, the present invention even allows a record processor to be re-purposed merely by the instruction content of the service processing record. A given general-purpose record processor may indeed have no intrinsic ability to process events within service processing records aside from the instructions conveyed within the service processing records themselves.